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(57) The system for distributing a digital content, 
created by a content provider (301 - 304), to a requester 
(200) through asharing networic (1 1 0), comprises a cen- 
tral authority (201 - 204) working on behalf of the content 
provider and a responder {3O0), registered with the cen- 
tral authority. 

When the responder (300) receives a request (1) 
for a content corresponding to a file stored on his/her 
computer, content purchase information data (4) are 
sent to the requester. The requester then buys the con- 
tent to the central authority and receives a proof of buy- 
ing (11). In responseto the sending of this proof of buy- 
ing to the responder, the requester receives the file cor- 
responding to the requested content. 

The responder then receives a compensation from 
the central authority for his/her participation in the dis- 
tribution of the content. 
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Description 

Field of the invention 

5 [0001] The invention relates to a system and a method for distributing digJtaf content through a sharing networJc, 
Background art 

[00021 Wt^h increasing use of the Internet, distributed sharing networks in which users propose digitai contents 
10 for sharing are beconning more and more popular Examples of such systems are the NAPSTER browser and commu- 
nication system (provided by Napster Inc.) allowing users to exchange MP3 files (audio files compressed using the 
MP3 compression fomnat - "MPS" standing for "Moving Picture Experts Group phase 1, audio layer 3") or the GNUTELLA 
distributed information sharing system (provided by Wego.com, Inc.). 

[0003J One problem encountered with these systems is that the contents are usually distributed for free by some 
15 users to others. The distribution protocols behind these systems do not take into account the right management of 
copyrighted contents and rely only on the goodwill of users. This results In a high piracy level and in Important losses 
for copyrighted content providers who are left outside these sharing networks and do not receive any Income for the 
distribution of the contents they have created. 

[0004] In document US-A-6 029 141 there is disclosed an Internet-based software system and method enabling 
^ entities called "associates' to market products (e.g, books) that are sold from a merchant Internet site, in return for a 
commission. However, this system and method does not contain any security feature and may be subject to attacks 
from hackers (for example to receive commission instead of the "real" associate). 

[0005] It is therefore an object of the present invention to provide a distributed sharing system in which copyrighted 
contents are protected against free distribution. Another object of the mvention is to propose a secure protocol enabltng 
25 secure commercial distribution of contents through sharing networks, 

Surrmar^ of the invention 

[0006] The invention relates to a system for distributing a digital content to a requester through a sharing network, 
30 characterized in that it comprises a central authority ; a responder, registered with said central authority^ having means 
for distributing a data file corresponding to said content to the requester in exchange of a proof of buying received from 
said requester. The central authority comprises : means for establishing a financial transaction with said requester for 
the payment by the requester of the content proposed by said responder and for delivering the proof of buying to said 
requester; and a responder compensation means for providing said responder with a compensation in exchange of 
35 the buying of a content by a requester 

[0007] The invention also relates to a method for distributing a digital content through a sharing network using the 
above mentioned system and comprising the steps consisting for a responder in: 

a) in response to a request for a digital content received from a requester through said sharing network, sending 
^ content purchase Information data to said req uester ; said content purchase Information data Including a responder 

identifier generated by a central authority and data identifying said central authority; 

b) receiving from said requester a proof of buying of said digital content, said proof of buying being delivered by 
said centraf authority ; 

c) providing said requester with a data file corresponding to said digital content; and 

45 d) receh/ing from said central authority a compensation for the distribution of said digital content. 

[0008] The Invention further relates to a method for distributing a digital content through a sharing network using the 
above mentioned system and comprising the steps consisting for a requester in: 

50 \) sending through said sharing network a first message to request a digital content: 

j) receiving content purchase information data from a responder having a data file corresponding to said content ; 
said content purchase information data including data identifying a central authority ; 

k) in response to a financial transaction with said central authority, receiving a proof of buying of said digital content; 
I) sending said proof of buying to said responder; and 
^ m) receiving a data file corresponding to said digital content. 
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Brief description of the drawings 

[0009] The various features and advantages of the present invention and its preferred embodiments wili now be 
described with reference to the accompanying drawings which are intended to illustrate and not to limit the scope of 
5 the present Invention and in whlc^: 

Frg. 1 illustrates the principle of an information sharing system. 
Fig. 2a to 2c illustrate an example of a sharing network architecture. 

Fig. 3 illustrate the preferred protocol for distributing digital content through a sharing network according to the 
10 invention. 

Description of the preferred embodiments 

10010] The present invention Is Independent of the underlying information sharing system but some mechanisms 
'5 used by these systems need to be understood before presenting the detarfed descnption of the invention. 

[0011] Fig. 1 illustrates an abstract model of an information sharing system 100 in which hosts 1 01 - 106 are Inter- 
connected through a sharing network 11 0, A host designates both a computer and a specific software which Is running 
on this computer to generate and to handle messages necessary to Implement the sharing network. Some users logged 
on these hosts can propose files containing digital contents for sharing with other users. These files include music files, 
^ video files, image files, computer program files^ etc. 

[0012] Once a user, for example logged on Hcst^ 1 01 , sends a request 120for a specific digital content on the sharing 
network 1 1 0, all users who are connected to the sharing network and who own files con-esponding to this request can 
respond by sending responses 1 30. These users are called responders whereas the user who has sent the request is 
a requester. 

^ [001 3] Upon receipt of the responses, the req uester can choose the files he is interested in and download these flies 
by establishing a peer-to-peer connection between the host on whk:h he is k>gged on and the host on whkrh the re- 
sponder is logged on. 

[0014] Each user connected to the sharing network can be a requester and a responder 

[0015] On Fig. 2a to 2c, an example of a sharing network architecture corresponding to the information sharing 
SO system of Fig. 1 rs presented. In this network, Host^ 101 is connected to Host2 102 and Hostg 106; Host^ 102 being 
itself connected to Host^ 1 03. Host4 104 and hibsts 1 05. Each partk;ipating host of the system acts both as a client (a 
program sending a request and waiting for a response) and as a server (a program which respond to a request). 
[0016] Each host 101 - 106 in the network can send a message to its neighbors in the network. Then, each host 
which receives a message forwards this message to its neighbors, resufting in a propagation of the message fn the 
35 network until the message has expired or all the hosts of the network have received the message. 

[0017] Fig. 2a illustrates such a routing system. In this example, a message M is first sent by Host^ 101 to its peers 
Host2 102 and Hostg 106. Then Host2 102 forwards this message M to its peers 103 - 105. At this moment, all the 
hosts of the network have received message M. 

[0018] Fig. 2b and 2c illustrate a request/response mechanism. In Fig. 2b, Host^ 101 submit a request RQ to its 
"to peers 102 and 1 06.Ttie request RO is forwarded until all the hosts of the network have received it (or until the request 
has expired). In this example, we suppose that Host^ 1 04 and Hostg 1 06 are able to give a response RS to the request 
RQ. In Fig. 2c, these hosts 104 and 1 06 send the response RS which is routed in the reverse direction of RQ to Host^ 
1 01 . If the request RQ corresponds to a request by a user logged on Host^ for a specific digital content, then the user 
can choose on which host 104 or 106 which have sent a response RS he will download the file containing the digital 
45 content. 

[0019] We will now present in more details the commercial distributed sharing system of the Invention and the secure 

protocol for distributing digital content in this system. 

[0020] This system comprises classical actors of a sharing system: 

^ - requesters, who represent users requesting file($) containing digital content on the sharing network; and 

responders, who represent users who propose files for sharing and wtio have locally on their computer files re- 
quested by requesters. 

[0021] Of course, as stated above, a same user may act as a requester and as a responder. 
S5 [0022] Contrary to known sharing systems of the prk>r art, in the system of the Invention, requesters pay for the 
content they want to receive and responders receive money each time they propose a content to a requester who later 
buys it. 

[0023] A new type of actor Is therefore added in the sharing system of the invention: the central authorities. These 
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entities are third parties who are responsible for selling contents on belialf of content providers. More specifically, they 
are responsible for collecting payments from requesters for contents which are sold on the network. They are also 
responsible for redistributing money both to the responder who distributed the content and to the content provider who 
created it, 

5 {0024] Each central authority works on behalf of one or, preferably, several content providers such as nnusic majors, 
book editors, software editors, etc. and rs responsible for the selling of contents produced by these particular content 
providers. It is also possible for one content provider to work with several central authorities to sell its contents on the 
sharing network. 

[0025] The purchase act is perfonned between the central authority and a requester who has found an interesting 
10 content proposed by a responder on the sharing network. The responder will receive later a compensation for having 
participated to the distribution of the content. 

[0026] However, before being able to distribute contents on the sharing network and to receh/e money from a central 
authonty working on behaff of content providers, afl potential responder must be registered with this centrai authority. 
If a responder wants to distribute contents (copyrighted files) created by several content providers which do not use 
the same central authority, the responder must be registered with all the central authorities involved before being able 
to propose the contents for sharing. 

[0027] The registration process may be periomied in several ways: for example, via e-mail (electronic mail) or via a 
registration zone on the central authority's Web site. At the end of the registration process, a unique responder identifier 
is attributed to the responder by the central authority and this responder identifier is sent to the responder and is stored 
20 jn a database of the central authority, 

[0028] Once a responder is registered with a central authority, he Is authorized to propose on the sharing networic 
contents created by content providers for which the central authority works on behalf of. 

[0029] Fig . 3 illustrates the actors Involved In the secure protocol of the invention for distrlbutirTg contents on a sharing 
network and the messages exchanged during this protocol. 
25 [0030] Four different content providers have been represented on Fig . 3: a book editor 30 1 , two music majors : M usk> 
Major^ 302 and Music Majorg 303 and a software editor 304. 

[0031] Four central authorities are also represented on Fig. 3. Central Authority^ 201 is working on behalf of the book 
editor 301 . Central Authohtyg 202 is working on behalf of the music major 302 while Central authorityg works for both 
music majors 302 and 303 and Central Authority4 works for the software editor 304, These links between content 
30 providers and central authorities are represented on Fig. 3 by continuous lines. 

[0032] It should be noted that the number of content providers and the number of central authorities are not linked 
and that each content provider may work with several central authorities. In the same way, each central authority may 
work on behalf of several content providers. 

[0033] In fact the term "central authority" used in the following of the description designates both the entity itself 
35 (which may be for example a merchant) andacomputerorserverof this entity on which a particular software is running 
to implement the protocol which will be described bellow. 

[0034] A requester 200 and a responder 300 are also represented on Fig. 3. We suppose that, before sending the 
first message to search for a specific content, the requester 200 and the responder 300 are both connected to the 
sharing network 110. The connection mechanism is out of the scope of the present invention and uses the underlying 
sharing protocol. 

[0035) The terms "requester" and "responder" as used bellow both designate on the one hand a computer and a 
software running on this computer forming a host of the sharing network, and on the other hand a natural person who 
is using this computer either for looking for a digital content on the sharing network (requester)^ or for proposing his/ 
her files containing digital contents for sharing (responder). Of course, as previously stated, a same natural person 
4s and host may be sometimes a requester and sometimes a responder. 

[0036] Fig. 3 illustrates more particulariy the messages exchanged by the actors described above during a search 
and a purchase of a dtgrtal content on the sharing network 110. 

[0037] In the following description of the protocol for distributing digital content, we suppose that all files (containing 
protected digital contents) requested by the requester have been produced by Central Authority^ 203 with which the 
so responder is registered. Of course, the responder may distribute files created by several central authorities. In that 
case, the responder must be registered with all these central authorities and must have a way to retrieve tiie right 
central authority according to the requested file. 

[0038] A possible implementation to create a file containing a protected digital content in a responder's computer 
wi(f be described bellow, 

55 [0039] If we take the example of audio cont^s, we suppose that the responder has bought a CD (acronym of 
"Compact Disc") containing several songs, this CD being produced by Music Majorg 303. If the responder wants to 
share these songs with potential requesters (and to receive compensation for that), he/she will first Insert the CD in 
the CD or DVD (acronym of "Digital Versatile Disc") player of his/her computer. Through the user interface of the sharing 
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network software running on his/her computer, tlie requester wit I choose which songs he/she wants to propose for 
sharing. Then, the central authority working on behalf of Music Majoir^ (here Central Authorltys 203) will be con- 
tacted by the responder for example by entering the URL (acronym of "Uniform Resource Locator" which defines a 
unique address fully specifying the location of a f Ho or other resource on the Internet) of Central Authoritys 203's Web 

5 site (IndFCated for example in the booklet accompanying the CD) on his/her Web browser 

[0040] If the responder has already been registered with Central Authorityg 203, then he/she will indicate the songs 
he/she wants to distribute on the sharing network and will receive from Central Authorltya 203 the corresponding files 
(containing the songs in a compressed format for example) comprising an identifier of Central Authority3203 and other 
information such as the price of the song. 

10 [0041 ] If the responder Is not registered with Central Authorityj 203, he/she will first have to register with this central 
authority as explained above before receiving the files corresponding to the songs he/she wants to propose for sharing. 
[0042] Then, the sharing network software running on the requester's computer will store the files received from 
Central Authoritys 203 on a particular place of the computer's storage medium. 

[0043] Referring back to Fig. 3, when a requester 200 sends a query to the sharing network 110 (message Query 
f3 sent at step 1), he/she receives responses when some users connected to the network have files satisfying the re- 
quester's query. 

[0044] In Fig. 3, we suppose that responder 300 has locally a file (or some files) that satisfies the query sent at step 
1 by the requester 200. If the file (i.e. the digital content) is available for free, then the classical protocol of the prior art 
is used. Otherwise, if the file (i,e. the content) is copyright-protected, the responder has locally an information about 

20 the price of the file. This price information has been previously delivered by the central authority (here Central Authority^ 
203) working on behalf of the content provider whk^h has produced the requested content (here Music Major^ 303). 
[0045] However, this price information has an expiration date allowing the central autiiority to change the price of 
the file over the time. If the prbe information stored by the responder (or more precisely stored in the storage medium 
of the respondor's computer) has expired, then the responder requests to Central Authoritys 203 a new price information 

^ for the particular file requested by the requester 200 by sending a PricefnfoRequest message 2. 

[0046] This PriCBlnfoRequest message 2 which is optional (It is not sent if the price information of the file stored by 
the responder has not expired) is illustrated in Fig, 3 with a dotted-llne arrow as will be Illustrated all optional messages 
which can be sent in the protocol of the invention, 

[0047] When the central authority 203 receives a Prk:einkyRequBst message 2, rt responds by a PriceinfoResponse 

30 message 3 containing the new price Information for the requested file. This message has an expiration date. It should 
be noted In addition that, preferably, the price Information returned by the central authority depends on the identity of 
the responder Indeed, some responders can actively participate to the distribution of copyright-protected files and thus 
can have agreements with central authorities to sell files at lower prices and/or have more Interested price margins. 
[0048] When the responder has a non-expired price Information of the file containing a digital content requested in 

35 the Oi/ery message 1 , It sends a QueryHits message 4 containing Infonnation that the requester needs to make his 
choice and to buy the file. This infonnation includes the file name, the file size, the quality of the file (e.g. a recording 
mode in case of audio ttles, version for a software file, etc), the price, the name of the central authority (or URL) where 
the file can be bought, the payment protocol accepted by the central authority, the responder identifier (generated by 
the central authority and given to the responder at the end of the registration process described above). 

4o [0049] In a preferred implementation, the sharing network software is running pemnanently on the responder's com- 
puter when the responder is connected to the sharing networi< 110 and the messages OueryHfts 4 and/or PrfcefnfoRe- 
quest 2 are generated automatically by this software without any inten/ention of the responder (as natural person). 
[0050] A requester may receive several QueryHits messages from different responders connected to the sharing 
network. Upon receipt of these responses to his/her query, the requester can make his/her choice. For example, the 

^ requester can choose the best price, make a tradeoff between the price and the quality or choose a preferred central 
authority with which he/she has preferential agreements, etc. 

[0051] While messages Query 1 and Queryhits 4 are routed between the requester 200 and the responder 300 
through the sharing network 110 (using a routing mechanism which depends on the underlying sharing system), once 
the requester has chosen one responder, it switches to a point-to-point communication with the responder A point-to- 
50 point communication (also known as "peer-to-peer" communication) consists in exchanging messages between two 
identified hosts of the sharing network contrary to the mechanism explained with reference to Fig. 2a to 2c. 
[0052] All other messages, described bellow, exchanged between the requester and the responder, are point-to- 
point messages. 

[0053] Furthermore, the requester may optionally ask for a preview of the file by sending a AskPreview message 5 
55 to the responder. This feature Is particularly interesting in the case of a copyright-protected file: It can be a short time 
of music in the case of musk; file, or a demonstration version In the case of a software, or a short clip in the case of 
video file, etc. 

[0054] If the requester 2CK) asked for a preview, the responder 300 responds by a Preview message 6 and sends 
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the requester a preview of the requested file. 

[0055] If the requester 200 decides to buy many files containing copyright-protected content (for example If the query 
consists in searching all the songs of one singer, then several files may correspond to this query), he can optionally 
ask for a preferential price by sending an InfoHequest message 7 to the rasponder 300. Upon receipt of this message, 
5 the responder 300 requests preferential prices on behalf of the requester200 by sending a PrfCBfnfoRequest messagB 
2 to the central authority 203 and receives a PhceinfoHesponae message 3 from the central authority 203. 
[0056] Then, the responder sends to the requester the preferential prices in the fnfoResponse message 8. If prefer- 
ential prices have not been accepted by the central authority, this message is empty. 

[0057] In a preferred embodtment, messages PricelnfoRequestZ and tnfoResponse 8 are generated automatically 

10 by the software running on the requester without any "human" intervention. 

[0058] If the requester 200 is satisfied with the conditions obtained from the responder 300, he/she is able to make 
the purchase of the requested file(s) by using the Infonnation contained in the QueryHits 4, and optionally tnfoReponse 
S, messages. Preferably the purchase act uses the World Wide Web to get the existing payment infrastructure. The 
requester 200 contacts the central authority 203 (using the central authority URL contained in the QueryHits message 

IS 4) and performs a secure Financial transaction 9 with the central authority During this transaction, the requester sends 
some data contained in the QueryHits message (such as responder identifier). The result of this transaction 9 is the 
payment of the central authority 203 for the copyright-protected file(s). 

[0059] The central authority will later be able to pay, on the one hand the content provider and, on the other hand 
Ihe responder 300 for his/her participation in the distribution of the file(s). Payment of the responder may be made by 
. ^0 crediting an account of the responder opened by the central authority during the registration process. 

[0060] At the end of the financial transaction 9, the central authority 203 delivers a payment ticket (sent in Payment- 
Ticket message 10) to the requester 200 that proves the requester has paid for the file(s). This payment tk^ket is 
forwarded to the responder 300 which has distributed the bought file(s) in a message Fv/dF^ymentTioket 11, Upon 
rccorpt of this message 1 1 , the responder 300 verifies the validity of the payment ticket and, if the verification succeeds, 
the responder responds by sending to the requester all information needed to download the requested file(s) in a 
Downioadtnfo message 1 2. Then, the requester 200 begins the Download operation 13 of the bought file(s), 
[0061 1 Given the sensittvity of some data contained rn the messages exchanged m the above described protocol, it 
is necessary to protect these messages against any possible attack during their transmission. 
[0062] We will now describe in further details the security needs of the system for distributing digital content according 
30 to the invention and how they are fulfilled in the preferred embodiment of the invention. 
[006^] The following notatbns and acronyms will be used throughout this descriptbn : 

denotes the concatenation operator; 

"{M}+" denotes the repetition of message M n times with n>0; 
^ "PBSK" denotes a signature verif k:ation public key; 

"PRSK" denotes a signature private key; 

"SK" denotes a symmetric key; 

"MK" denotes a master symmetric key; 

"DK" denotes a derived symmetric key; 
40 "SSK" denotes a symmetric session key; 

"EsK denotes the symmetric encryption of message W using the symmetric key SK; 

"Spptsi^ (M)" denotes the signature of message M using A's signature private key PBSK; 

"H (IV!)" denotes the hash value of message M using hash function H. 

45 [0064] Preferably, the following cryptographic algorithms will be used to implement the system and method of the 
fnventk>n : 

"AES" (acronym of ^'Advanced Encryption Standard") will be used for symmetric encryption. More details about 
the AES standard can be found in the Internet publication "NJST, "^Adanced Encryption Standard Deveiopment 
so Effort^ at http://cstic.nist.gov/encryption/aes" and In "DAEMEN J. and RUMEN V., 'The Rljndael Block Cipher', 

AES Proposal, at http://csrc.nist,gov/encryption/aes/rijndaei/Rijndael.pdf". 

"RSA" (acronym of "Rivest Shamir Adelmart' the names of the creators of this algorithm) with "SHA-1" as hash 
function will be used as signature algorithm. This algorithm will be used in accordance with the standard PKCS#1 
v2.1 described in the following Internet publication: "RSA LABORATORIES, "PKCS #f v2.1:,RSA Cryptography 
55 Standard", September 1 999 (draft status), http://www,rsalab8.com/pkcs/pkcs-1 

"SHA-1" will be used as hash function H (infonnation about SHA-1 function can be found in "W/STJ SIPS PUB 
180-1, "Secure Hash Standards", Avrii 1995). 
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[0065] in the preferred implementation of the invention , the size of the cryptographic keys is the foifowing: 

1 024 bits for signature keysr 
128 bits for symmetric keys, 

5 

[0066] At first, the system should guarantee to requesters: 

a) Anonymity: the responder should not know the identity of the requester. He/she should not be able to link several 
purchases, i.e, to know whether two different purchases are from the same requester or not. 

10 To ensure this anonymity, in a preferred implementation, the identity of the requestor is hidden behind its IP 

address (IP being the acronym of "Internet Protocol"). As in most of cases, this address is dynamically attributed 
at each Internet connection; therefore the responder is not able to link two different requests. 

b) Security of Payment the responder should be sure that his/her payment is secure. 

This is ensured by the payment protocol itself used in the financial transaction 9 whatever it is, for example 
'5 SET (acronym of "Secure Eiectronic Transaction", infonnation about which can be found in "Loeb L., ''Secure 

Electronic Transactions: Introduction and Tte/rn/ba/ Reference", Artech House Publishers. 1998") or SSL (acronym 
of "Secure Socket Layer*, a well-known payment protocol used on the Internet) or a micropayment protocoL 

c) Proof of buying: \he responder should be sure that the proof of buying he/she gets (i.e. the payment ticket 
received m message 1 0) from the central authority is valid and wiil always allow him/her to get the fiie he/she 

20 bought. Nobody else than him/her may use that proof of buying. In addition, the responder should have the ablllly 

to verify that proof which shouki also be checkable by the responder 

In a preferred embodiment, the proof of buying, i.e. the payment ticket, is signed by the central authority (using 
a signature private key PRSK^y^ as further explained bellow) before being transmitted to the requester to prove its 
validity This signed payment ticket preferably includes infomnation on the bought content and the identity of the 

25 responder (i.e. the responder identifier which has been received by the requester in the QueryHits message 4). 

In addition, in order not to be used by a hacker who may intercept the Ps^mentTicket message 1 0, the latter 
(in fact the signed payment ticket) is further encrypted by the central authority before being transmitted to the 
requester It is encrypted using a key Kp^y ^^^^ already been used (or generated) in the payment protocol used 
during the financial transaction 9 and which is shared by the requester and the central authority. For example SET 

50 and SSL protocols define such keys. 

Moreover, In order to secure the transmission of the payment tk^ket between the requester and the responder 
In the FwdP^ymentTidcet message 11, a symmetric session key SSK Is used to create an encrypted channel 
between the requester and the responder for the transmission of the FwdF^ymentTicket message 11 . The way 
this key SSK is generated by the central authority and shared by both the requester and the responder will be 

3S further detailed belk>w. 

[0067] The system should further guarantee to responders: 

a) Privacy, nobody else than the relevant responder may obtain Information (prices, reductions... which may be 
40 different for each responder) on conrYnencial agreements made with a central authority. 

To ensure this privacy, in a preferred implementation the PhceinfoResponse message 3 Is encrypted by the 
central authority before its transmission to the responder in such a way that only the right responder is able to 
decrypt it Preferably, it is encrypted using a symmetric encryption key DKpR which is generated by the central 
authority during the responder's registration process and which is derived from a master key MKpf^ (only known 
^5 by the central authority) and from the responder identifier This key DKpp^, vt^ich Is different for each responder, 

is sent by the central authority to the re^sonder at the end of the registration process together with the responder 
identifier. If a responder tries to know the price conditions of one concurrent, he wilt receive them encrypted and 
will not be able to decrypt them. 

b) Rigt%tness of pricing: the responder should be sure that the price information received from a central authority 
so in the PriceinfoResponse message 3 is valid and will thus be further accepted by this authority. 

In a preferred embodiment, the price information is srgrred by the central authority (using the signature private 
key PRSKq;^) before being transmitted to the responder In the PriceinfoResponse message 3. Preferably, the 
signed price information contains some information on the file proposed for sharing, the price, the time limit of the 
price validity, the responder identifier, some information about the quality of the file, the modes of payment accepted 
55 by the central authority and the central authority URL. 

c) Assurance of payment nobody else than the relevant responder shoukJ obtain payment from a central authority. 

This is ensured In the prefen-ed Implernentation by the presentation of the proof of buying (i.e. payment ticket) 
to the responder (in the FwdPa^mentTlcketmess^^e 11), since the responder Identifier is included in that proof 
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which is generated by the central authority. 

d) ConfkfentialHy: the download Information transmitted to the requester In the Downfoadlnfo message 12 and the 
content to be downloaded during Dou^/oacf operation 13 are to be kept confidential during their transmission to 
the requester 

5 This is ensured in the preferred embodiment by the presence of an encrypted channel between the responder 

and the requester, this encrypted channel being created thanks to a symmetric session key SSK as it will be further 
described bellow. 

e) Restriction to the purchase:\i should be ensured that the requests may get nothing from the responder but the 
content he bought, 

10 In a preferred Implementation, the responder's computer has a permanent directory where all the contents (i. 

e. all the files received from central authorities when the responder has acquired the right to distribute the contents 
on the sharing network) are available in an encrypted fomn (each content being encrypted with its proper key 
^content) Then, the responder transmits the decryption key Kcontent bought content (via the encrypted chan- 
nel) to the requester in the Downtoadlnfo message 12 and the content itself is transmitted In its encrypted form 

IS (using key Kcontent) the requester in the Ooivn/oacf operation 13, Integrity of the content may be obtained by 

including hi the encrypted content transmitted the hash value of the content. 

An alternative solution would be for the responder to dynamically create a directory in which the bought files 
are placed. This directory would be destroyed after the Ooivn/oacf operation 13 occurs. The content will have to 
be encrypted on the fly by the responder to be sent, through the encrypted channel, to the requester. 

so 

[0068] Finally, the system should ensure to central authorities the validity of payment (i.e. the fact that the payment 
they receive is valid). This is ensured by the payment protocol used in the Financial transaction 9. 
[0069] In order to implement the preferred embodiments that have been described to ensure security in the protocol 
of the invention, several cryptographic keys need to be generated and shared by the actors of the system as it will be 
described bellow, 

[0070] At first each central authority has a signature private key PRSK^a which is used to certify the prices and the 
payments. The associated signature verification public key PBSK^^ will need to be certified. In a preferred solution, 
we propose to use cross-certification between the different ceotraJ authorities which avoids building a heavy Public 
Key Infrastructure. The requester will then have to toist at least one central authority, 
30 [0071] Moreover, each central authority has also two master symmetric keys MKpp (to protect the transmission of 
the price infonrtation in the PricefnfoResponse message 3) and MK^o (to buifd an encrypted channel between the 
responder and the requester). Central authorities will distribute to each responder at its registration, in addition to its 
responder identifier, two derived keys : 

35 0^<PR = Ei^KpR {responder identifier); and 

^^EC - ^mkec {''^^^ponctef identifier), 

[0072] As for the responders, they need to get at their registration the two derived keys DKpp and DK^c They also 
have to create a symmetric key K^of^^ for each content they wjll drstrlbute through the sharing network. Each content 
40 wHI be stored in a specific directory of the responder in the following form: 

[0073] Regarding requesters, they do not need any dedicated key beforehand. However, they wili use a key Kp^y 
45 that Is used and / or built in the payment protocol used in the financial transaction 9. This key Kp^y is used to encrypt 
the payment ticket transmitted between the central authority and the requester in message PaymentTicket 1 0. 
[0074] Finally, one symmetric sesskin key SSK is created at each purchase of a content. This key SSK will be used 
to create an encrypted channel between the requester and the responder The key SSK is created by the central 
authority after the financial transactk>n 9 (during when the responder identifier has been transmitted to it). The central 
so authority first generates a random value R. Then, it c^cufates SSK=EDKec t*^)* ^^^c *® reconstructed by the 

central authority from the master key MK^q and the responder identifier: 

DKec = ^mkec fr^^P^r^cier identifier). 

55 [0075] The session key SSK is transmitted, together with the random value R, to the requester in the f^ymentTtcket 

message 1 0 (encrypted with key Kp^y). Then, the requester sends the random value R to the responder which is able 
to calculate SSK= ^oK^c ^^^^ ^^"^ '^'^EC Finally, both the requester and the responder share the same session 
key SSK and can therefore built an encrypted channel. 
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[0076] in the foflowing part of the descrrption, we wril propose a more detailed description of the mternal content of 
the messages 1 *13 exchanged in the protocol illustrated In Fig. 3. This description is of course a possible Implemen- 
tation and should not be understood as limiting the scope of the invention. 

1 , Query message 1 : 

[0077] This message is sent by a requester to search for specific ffle(s) in the sharing network 1 1 0. For this purpose^ 
the requester types a search criterion describing the requested file(s). For example, a '*britneyspears*.mp3'' search 
criterion may indicate that the requester is looking for all shared MPS files for which the artist is "Britney Spears", 
[IX>7S] The detatJed message format is presented in Table 1 bellow: 

Table 1 



Fields of message 


Description of the fieids 


Query m^ssagB data 


{Minimum speed, Sear^ cfiimri^ 


Minimum speed (2 bytes) 


Minimum speed (in KB/second) of hosts that should respond to this message 
with a message. 


Search Criteria (variable 
length) 


Null-tenninated search string. 



20 



2. PhcelnfoRequest message 2: 

[0079] This message is sent by a responderto a central authority to request purchase informah'on (prrce, payment 
2s schemes accepted by the central authority, etc.) for copyrighted files proposed by the responder for sharing. In practice, 
the responder has locally purchase infonmation for all of his copyrighted-shared files. However, this information has 
an expiration date and must therefore be refreshed on a regular basis, 
[0080] This message can be sent at different times during the procedure: 

30 - at first it can be sent by the responder before he proposes copyrighted files for sharing. In that case, the nesponder 
uses this message to have an initial purchase Information; 

secondly, ft can be sent after the responder has received an InfoRequest message 7 from the requester. The 
InfoRequest message 7 is used by a requester to have preferential prices in some situations (for example when 
the requester decides to buy many files); 
;35 - it can also be sent each time a responder detect that some local purchase infomiation has expired. 



[0081 1 This PncefnfoRequestmessage 2 also contains inf omiation about the responder identity. Indeed, the respond- 
er can negotiate in an out of band way with central authorities his price margins and/or preferential prices proposed to 
the requesters. Therefore, the presence of the responder identity In this message allows the central authority to propose 
4Q the right prices according to the responder. 

[0082] The detailed message forniat is presented in Table 2 bellow: 

Table 2 



Fieids of message 


Description of the fieids 


PricelnfoRequest message 
data 


{ResponderlD, ReqPurcljaseNumber, {ReqPurcha8elnfo}4-} 


R^ponderiD (32 bytes) 


Responder identifier generated by the central authority during the responder 
registration. 


ReqPhceN^m^r{^ byte) 


Number of requested purchase infonnation. 


ReqPurchasekifo 


{mielndex, FUeSIze, FileName, Chiailtyi 


Fiteindex (4 bytes) 


Unique identifier representing the file for which the responder requests price 
information. 


F//eS/ze(4bytes) 


Size (in bytes) of the fife indexed by Fife/ndex. 



45 



SO 



55 
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Table 2 (continued) 



Fields of message^ 


Description of the fields 


PriceinfoRequest message 
data 


{ResponderfD, ReqPurchsseNumber, {ReqPurchasefnfo}+} 


FiieNamc (variable length) 


Double-null terminated string representing the name of the local file indexed by 


Quality (variable length) 


Double-null tenmlnated string representing a quality nneasure of the file indexed 
by Fifefndex. 



[0083] It should be noted that: 

the ReqPurchaselnfo field appears ReqPurchaseNumbert\mes in the PriceinfoRequest message 2 (one for each 
file for which the responder needs purchase information); 

the set (Rieindex, fUeSize, FHeName, Quality} must uniquely identify a same file at the responder side and at the 
central authority side. This ensures that the central authority is able to give the right price to the responder. For 
this purpose, Fileindex can use a mechanism similar to ISBN for books numbering ('ISBN" Is the acronym of 
International Standard Book Number*). 

3. PricelnfoResponse message 3: 

[0084] This message is sent by the central authority to the responder and contains purchase Information requested 
by the responder In the PriceinfoRequest message 2. This purchase infomnaticn includes all infomiation needed by a 
requester to choose a fife to download once he has sent a query and he has received responses from responders. Aff 
proposed purchase information has an expiration date and once this information is received by the responder, it must 
be stored by the responder until this date. 

[0085] As prevfously stated, this message should be confidentiaf. The data it contains are therefore encrypted with 

the symmetric key DKpR t>efore being sent to the responder, 

[0086] The detailed message fomnat Is presented in Table 3 bellow: 



Table 3 



Fields of message 


Description of the fields 


PrtcelnfoResponse message 

data 


[EnayptedPrlcelnfbResponsefl^ 


BncryptedPricelnfoResponse 


Edkpp, [PurchaselnfoNumber,{SignedPurchasel rtft>}+) 


PurchaselnfoNumter {A byte) 


Number of purchase information contained in the message. 


SignedPurehasmfnfo 


®RRSK iPuric:hBBeMo) 


Purchaseinfo 


[Fileindex, FileSIn, FileName, Quality, Price, PrlceVaUdlty, 
MerchantName, Paymenmode, CA_URL^ RespottderlD^ 


Fileindex (4 bytes) 


Uniquefile identifier This field is extracted from the Pr/ce/n/oAeQi/esf message 
2. 


FlleSIze (4 bytes) 


Size (in bytes) of the file indexed by Fileindex, This field is extracted from the 
PriceinfoRequest message 2. 


FileName (vartabfe iength) 


Doirbie-null termmated string representing the name of the focaf fiJe mdexed 
by Fttetndex. This field is extracted from the PriceinfoRequest vc^essBgi^ 2. 


Qualffy (variable length) 


Doubie-n uli terminated string representing a quality measu re of the file indexed 
by FUelndex, This field is extracted from the PriceinfoRequest message 2. 
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Table 3 (continued) 





Fields of message 


Description of the fields 


5 


PricelnfoResponse message 
data 


{EncryptedPriceinfoResponsei 


10 


Price (variEible length) 


Double-null terminated string indicating the price of the file indexed by 
Fileindex, This field is formed by three sub-fields separated each other by null 
character: "Currency', "Amourtf, "AmtExpW, Cu/rency specifies the three- 
digit ISO 421 7 currency code. Amount represents the amount of payment. 

f\fIHCJlfJi\JliSfJtw^^^liVo ait BJlLnJI Ic7l IL UdiB^ I\i SU^fl LIlCll CflllUUIIi ^ i u*"'"~'''T' ^ 

shall be the value in the minor unit of the currency specified in ISO 421 7. 


15 


PriceVaiidny (variable length) 


Double-null terminated string indicating the time during which the proposed 
Drtce i& v^^lld for the fil6 indexed bv Pif^tmiey After this time the re^oonder 
will have to request new purchase information. 




M0rchat7tNBnw (variable length) 


Double-null terminated string representing a human readable name of the 
central authority responsible for the selling of the file indexed by Fifetndex, 


SO 


PaymentMocfe (variable length) 


Double-null terminated string representing the payment schemes acceptable 
by th e central authority for the purchase of the correspondingf i le. The schemes 
are separated from each other's by a null character. 


25 


CA_URL (variable length) 


Double-null terminated string indicating the URL of the central authority that 
will sell the file indexed by Fifefnd&cxo requesters. A payment server accepting 
ttie payment protocols indicated in the PaymentMode field must run at this 
URL. 




ResponderfD (variable length) 


Unique identifier generated by the central authority during the registration of 
the responder that emitted the PricefrifoRequest message 2, 
This field is extracted from the PncelrtfoRequest message. 


30 


4. QtMeryHHs message 4: 





[0087] This message is sent by a responder in response to a Query message 1 received from a requester If a 
responder has locally files that correspond to the requester's query, the responder responds by a QueryHits message 
35 4. This message should contain all data needed by the requester to make his/her choice. 
[0088] This choice can be made on several bases: 

the price: the requester should know the price of copyrighted files; 

the price/quaiity tradeoff: the requester should know the quality for the proposed fifes. Therefore, a quality measure 
40 has to be proposed by the commercial distributed sharing system; 

the accepted payment systems: the requester should know if he is able to pay the requested files with the proposed 

payment schemes; 

the merchant name (i.e. central ^hority name): the requester may have preferential relationships with some 
merchants, 

45 

[0009] All these data have been originally generated l^y the central authority, which is responsible for the selling of 
the corresponding files. Therefore, most part of this message is extracted from the PricetnfoResponse message 2. 
[0090] Moreover, this message proposes an optional field representing the personal responder*s Web site URL al- 
lowing the requester to get personal information on the responder This field can be useful in the case where the 
so requester detects that the responder has many interesting files. By giving his/her Web site address, the responder 
provides the requester with a way to access value-added services such as complete file catalogue, e-mail service, 
chat, etc. 

[0091] The detailed message format is presented in Table 4 bellow: 

55 
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Table 4 



Fields of message 


Descnption of the fielas 


QueryHiis message data 


{MHNumber, PortNumber, tPAddress, Speed, [ResponderURQ, 
{SignedPufchaselnfo}^} 


HftNumberii byte) 


Number of shared files proposed by the responder that satisfy the requester's 
query. 


PortNumber (2 bytes) 


Transport-layer port number that the requester must use if he decides to use 
this responder as the file seller. 


/P>ldtfrBss(4bytes) 


Responder's fP address that the requester must use if he decides to use this 
responder as the file seller. 


Speed (4 bytes) 


Speed (In KB/second) of the responder 


length) 


U/l.f UUIC^I lUM LCI 1 1 III IClLtfU oil n 1^ LlldL IIIUI^'ClLwO U\KS cl1JU[Bd«> Ui LI IC? lc;a]JUIIUCl 4 

personal Web site. 

This field is optional and can be used by the requester to find responder's 
personal infomation and other value-added services (chat, e-mail, etc.). 


SignedPurchaseinto 


This field contains all information about the files proposed by the responder for 
sharing and that satisfy the requester's query. Thrs field has been generated 
and signed by the central authority to build the PricetnfoResponse message 3 
and is extracted from this message. 



[00921 It should be noted that: 



the SignBdPurchaseinfo field appears HitNumbenmes in the QueryHits messagfe 4 (one for each file satisfying 
the requesters request); 

the prices given by the responder in this message are imposed by the central authority working for the content 
providers which have produced the corresponding contents. These prices are known by the responder thanks to 
the PrfcetntoRequestfPilcefnfoResponse messages pair 

5. >lsJirFrevleMr message 5: 

[0093] This optional message is sent by the requester to ask for a preview of a specific file. This message is sent 
once the requester has received a QueryHits message 4. By choosing a specific file in the list of responders' proposi- 
tions: the requester can receive a preview of the file by sending this message. 

[0094] It shouki be noted that this message is a point-to-point message and thus does not traverse the sharing 
network 110, For this purpose, it uses the If^ddress and p9/tA/LRn7ter fields received from the responder in the Que- 
ryHits message 4. 

[0095] The detailed message format is presented in Table 5 bellow: 



Table 5 



Fields of message 


Description of the fields 


AskPreview message 
data 


IFIielndex, FileSIze, Filefiame, Quality\ 


F/M/fdex(4bytes) 


Unique file identifier This field is extracted from the Query Hits message 4. 


FiieSae(4 bytes) 


Size (Jn bytes) of the file indexed by Fife/ndex. 

This field is extracted from the QueryHits message 4. 


FlieName (variable length) 


Double-null terminated string representing the name of the local file Indexed by 
Fifeindex. This field is extracted from the QueryHits message 4. 


Quatlty (variable length) 


Double-null terminated string representing a quality measure of the file indexed by 
Fifeindex. 

This field is extracted from the Oue/yW;sf message 4. 
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6. Preview message 6: 

[0096] This message is used by the responder to send a preview requested by the requester in the AskPrevi&v 
message 5. The sent preview Is not interpreted by the requester's client software but locally stored for being iater 
played by the adequate player. 

[0097] The detailed message format is presented in Table 6 bellow: 



Table 6 



Fields of message 


Description of the fields 


Preview message data 


iFHeindex, FiieSize^ FiieName, BstSireani^ 


F//eintfex (4 bytes) 


Unique file identifier This field is extracted from the AskPreview message 5. 


FiieSize (4 bytes) 


Size (in bytes) of th& file indexed by Fifeindex. 

This field is e>ctracted from the AskPreview message 5, 


FiieName (variable length) 


Double-null terminated string representing the name of the local file indexed by 
FifekKtex, This field Is extracted from the As/cF>w-few message 5. 


BitStream (variable 
length) 


BitStream representing the preview requested by the requester in the AskPreview 
message 5. 



7. InfoRequest message 7: 



[0098] This message is optional and is used by the requester to receive preferential prices for a set of fifes chosen 
from a previously received Otje/yH/fs message 4, This message is typically used when a requester wants to buy many 
files that can justify such preferential prices. Upon receipt of this message, the responder will send a new PricetnfoRe- 
quest message 2 to the central authority in order to get fresh price infonnatian. 

[OOdd] Contrary to Query and QueryHits messages 1 and 2, this message Is directly sent, through a point-to-point 
connection, to the responder by using the IPAddress and PortNumberfiel^ contained in the QuerylHts message 4. 
Therefore, this message Is not routed through the sharing network 110. 
[0100] The detailed message format is presented in Table 7 bellow: 



Table 7 



Fields of message 


Description of the fields 


fnfoRequest message 
data 


{ReqlnfdNwnber, iReqFileinfol4'} 


ReqtnfoNumi>er (t byte) 


Number of shared files proposed by the responder and for which the requester wants 
to get purchase information. 


ReqFllelnIb 


{FUelndex, FOeSize, FiieName, Qualli^ 


FiMndex (4 bytes) 


File index used to uniquely identify the file for which the requester asks purchase 
information. 

This field is extracted from the QueryHits message 4. 


FUeSize (4 bytes) 


Size (in bytes) of the file Indexed \yy FiteifKiex and for which the requester asks 
purchase information. This field is extracted from the QueryHits message 4, 


FiieName (variable length) 


Double-null terminated string representing the name of the local file indexed by 
Fifetndex and for which the requester asks purchase infonmatton. 
This field Is extracted from the QueryHits message 4. 


Quality (variable length) 


Double-null tenninated string representing a quality measure of the file indexed by 
FUefndex and for which the requester asks purchase information. This field is 
extracted from the QueryHits message 4. 



[0101] It should be noted that the ReqFifeinfo field appears fteqintoiSlumber times in the int^Request message 7 
(one for each file for which the requester needs purchase information). 
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8. infoRBSpoitse message 8: 

[0102] This message contains all purchase Information requested by the requester In the fnfoRequest message 7. 
Moreover, this message proposes an optional field representing the personal responder's Web site URL allowing the 
s requester to get personal information on the responder. This field can be useful In the case where the requester detects 
that the responder has many jnterestrng flies. By gtving his Web site address, the responder provides the requester 
with a way to access value-added services such as complete file catalogue, e-mail service* chat, etc. 
[01 03] As the InfoRequest message 7, this message does not traverse the sharing network 110 but is directly sent 
to the requester. 

10 [0104] The detailed message fomnat is presented in Table 8 bellow: 



Table 8 





Fields of message 


Description of the fields 


15 


IntoR^Bponsm messsga data 


{jiRBsponderURL\^ Purchas^lnUyNumber, 
{SigttedPurchsselnfo} ^} 


20 


ResponderURL (variable ResponderURL (variable 
length) 


If present, this field Indicates the responder's Web site 
address at which the requester can fin value-added 

services. 


PurchaseinfoNumber ( 1 byte) 


Number of purchase information contained in this 

message. 


25 


SfgnBdPurchasetnfo 


This field is the same as the one generated in the 
PricelnfoRe&ponse message 3 and contains all price 
information requested by the requester 



[0105] It should be noted that: 



the SignedPurchasefnfo field appears PurchasefntoNumber times in the infoResponse message 8 (one for each 
^ file for which the requester needs purchase information); 

theoretically (in the best case), the PurchasefntoNumber f\e\d has the same value as the ReqfnfoNumbert\e\d of 

the fnfoR&questm&ssa^QG 7. However in some malfunction cases (central authority shutdown, database crashing, 

etc.), the responder may be unable to send pu rc^se information about some files. \n this case, we have Pur- 

chase/nk>Number< ReqfnfoNumber, 
^ ' upon receipt of this message 8, the requester should verify that the received infomnation matches the one he 

requested. If the verification fails, an adapted behavior should be taken by the requester A reasonable behavior 

would consist to skip all purchase information that do not match. 

9. Financiai transaction 9: 

40 

[0106] This section does not cover a special message but a suite of messages resulting in the payment of the central 
authority by the requester for the requested files. The payment phase is out of the scope of the invention and can be 
implemented by any payment protocol (e.g. SET, SSL, micropayment, etc.) supported by the central au^ority (i.e. 
those which have been sent in the QueryHits and InfoResponse messages 4 and 8). 
^ [01 07] However, the payment phase should be preceded by a negotiation phase in which the requester presents an 
order f omi and the payment scheme he/she chooses among the list of accepted payment protocols. This information 
is extracted from the infoResponse or QueryHits messages previously received by the requester. 
[0108J Table 9 bellow presents the Negotiation message sent by the requester to the central authority: 

50 Tables 



Fields of message 


Description of the fields 


NegaUation message data 


{FlieNumber, ChosenPaymentModaj {SlgnedPwchaselnfd}-^} 


FneNumber{\ byte) 


Number of files thai the user wants to buy to this central authority. 
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Table 9 (continued) 



Fields of message 


Description of the fields 


Negotiation message data 


{FiieNumber, ChtjsenPaymentMod^, {SggnedPur^^tasetnfo}+} 


ChosenPaym&ntMode (variable 
length) 


Double-nuli terminated string representing the payment scheme chosen 
by the requester to pay the corresponding file. This field must beiong to 
the PaymentMode sub-field of the SignedPurchaselnfo tietd of the 
QueryHits message 4. 


SignedPurchasetnfo (variable length) 


Data set representing a file that the requester wants to buy This set is 
retrieved from the Oue/yH/fs message 4 or the infoHesponse message 
8 and has been originafly generated and signed by the central authority 
contacted by the requester for the purchase. 



[01 09] it shouf d be noted that: 



the SignedPurchasetnfo field appears FifeNumber Xmes in the Negotiation message (one for each file that the 
requester wants to buy); 

Before launching the financial transaction, the central authority verifies the validity of the presented price informa- 
tion and the responder Identifier contained In the SignedPurciiaseink>i\e\6. If the verification fails, the transaction 
is cancelled. 

1 0. PaymentTicket message 1 0: 



[01 1 0] This message is delivered by the central authority to the requester once the financial transaction is completed . 
[0111] The detailed message fonnat is presented In Table 1 0 bellow: 



Table 10 



Fields of message 


Description of the fields 


PaymentTicket message 
data 


[SncryptedPaymentlicketi 


EncryptedPaymentTieket 


iSignedPaymentTlcket, Challenge^ SSK) 


SignedPaymentTicket 


S^^ [fiesponderlD, li^nsactlonNumber, {7tansactionlnk>i+) 


ResponderfD (32 bytes) 


Responder identifier used by the central authority during the purchase of the 
corresponding files. 


TraasactionNumber (1 byte) 


Number of files that the requester has paid. 


Transactiontnfo 


{FHeh^dex, FUeSize, FHeName, Qualityi 


FifeindGx (4 bytes) 


Unique file identifier representing the corresponding ffle paid by the requester 


Fi^isx (4 bytes) 


Size (in t>ytes) of the file indexed by Fitelndex. 


FileMame (variable length) 


Double-nuli tenmlnated string representing the name of the local file Indexed by 
Fitetndex. 


Quality (variable length) 


Double-null temiinated string representing a quality measure of the file Indexed 
by Fifelnd&x. 


Challenge (1 6 bytes) 


Random value generated by the central authority to derive the session key SSK, 


5SK (16 bytes) 


Session l<ey to be shared between the requester and the responder: SSK=Eqk^ 
(Challenge). 



[0112] It should be noted that the Transacf/on/n/b field appears TransactionNuml>en\me& in the PaymentTtt^etmes,- 
55 sage 1 0 (one for each file that the requester paid). 
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1 1 . FwdPaymentTicket message 1 1 : 



[01131 This message is sent by the requester to the responder to prove that he/she has bought some copyright- 
protected files. This message contains about the sanr^e data than the PaymentTtcketvnessagB 10. 
[0114] The detailed message format is presented in Table 11 bellow: 

Table 11 





Relds of message 


Description of the fields 


10 


FwdPaymentTicket message data 


{EncryptedFwdPaymentTickmli 




EncryptedFwdPaymentTicket 


^SSK (SfgnedPaymentTickef^, Challenge 


15 


SignedRBymeniTicket (variable 
length) 


SJgnedPaynientTicketf\Q\d that was generated by the central authority as 
a proof of buying and which is extracted from the P^menfT/c^ef message 

10. 




Chaiienge (1 6 bytes) 


C/)affenge generated by the central authority and which is extracted from 
the PaymentTicket message 1 0. It will be used by the responder to 
calculate the session key SSK. 


20 


12. Dovmfaadfnfo message 12: 





2S 
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[0115] This message is sent by the responder to the requester once he received the FwdPaymentTicket message 
11 proving that the requester paid some files, in this message, the responder gives the (JRL at which the requester 
can ask the download of the bought files. For facility purpose, we propose to use the HTTP protocol for the download 
phase. Therefore, an HTTP server should run at the URL contained in the Downk)adlnk> message 12, 
[0116] Moreover, in order to secure the download phase against eavesdropping, the downloaded files will be en- 
crypted. The Downfoadtnfo message 12 therefore also contains the decryption key that will be used by the requester 
to retrieve the original bought files. 

[0117] In addrtlon, this feature prevents the requester to download files other than those he bought. 
[0118] The detailed message format Is presented in Table 12 bellow: 

Table 12 



Fields of message 


Description of the fields 


DownlOBdinfo message data 


[EncryptcdDownioadfnfo] 


EncrypfedDowntoaeUttfd 


E33K l{FilGDownloadinto}4; DownloadURL) 


FiieDownioadfttfo 


{FlleName, ContentKe^ 


FffeName (variable length) 


Null-terminated string representing the name of the file to be downloaded. 


ContmtKey (1 8 bytes) 


Decryption l<ey of the relevant file (K^rrtcni) 


DownloadURL (variable 
length) 


Null-terminated string representing the URL at which the requester can download 
the bought litas. 



[01 1 9] It should be noted that upon receipt of this message, the requester should verify that the number of received 
downloaded information conrespond to the number of bought files. 



50 



13. Download opewMon 13: 

[0120] Once the requester receives the Dovmfoadlnfo message 12, he/she can begin the download phase 1 3. 
[0121] Table 13 bellow illustrates the content format downloaded by the requester. As underlined previously, this 
content is encrypted preventing thus eavesdropping. 
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Table 13 



Fields of message 


Description of tiie fields 


ContrntDowniaad 
format 


{EncrypteciConten^ 


EncryptmdContont 


^Kcctem ICheckabieContBnfi 


CifeckabieConteitt 


{HashedConient, Content^ 


HashedContent (20 

bytes) 


Hash value of the Content This will be used to check that the content has been 
downloaded without any transmission problem. 


Content (variable Jength) 


Bought bitstream. 



[0122] We will now describe the preferred method to provide responders with their compensation for the distribution 
of digital content through the sharing network. Indeed, each time a content which has been distributed by a responder 
is bought by a requester, the responder should receive a corresponding payment from the CBr\lra\ authority. 
[0123] As previously stated, all responders who distribute digital contents through the sharing network must be reg- 
istered with at least one central authority in order to receive compensation for this distribution. A same responder can 
be registered with several central authorities if he/she proposes copyrighted contents created by different content 
providers which are not linked to the same centra) authority. 

[01 24] In the preferred method for paying responders, it is proposed to create an account for each responder during 
the registration phase, this account being linked to the responder Identifier, During the registration, the responder gives 
to the central authority all personal data (name, address, bank account number, etc.) needed by the central authority 
to perform account clearing. Then, on a reguiar basis, the central authority with which the responder is registered 
perfonns an account clearing resulting in the payment of the responder. The clearing method should be negotiated 
between the central authority and the responder during the registration phase, and is out of scope of the invention. 
[0125] During the purchase of a copyrighted content, the central authority credits the responder's account once It 
receives the A/egof/attonmessageof the financial transaction 9. As underlined in section 9 above, this message contains 
the responder identifier, which has been delivered by the central authority. The central authority has thus all needed 
data to pay the responder. 

[0126] An alternative solution would consist for the responder to present the PaymenfT/c^fef message data received 
from the requesters (in FwdPs^mentTk^t messages 11 ] to the central authority for being paid. Once the responder 
receives PaymentTicket jmessage data, he/she stores it as a proof of selling. On the other side, the central authorities 
store all generated Paymenf 77c#ref messages. Then, the responder presents these messages to each central authority, 
which can verify the validity of the message before performing an online financial transaction with the responder 
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Ciaims 

1» System for distributing a digital content to a requester (200) through a sharing network (110), diaracterised In 
that ft comprises: 



a central authority (201 - 204) ; 

a responder (300), registered with said central authority, having means for distributing a data file corresponding 
to said content to said requester (200) in exchange of a proof of buying (11) received from said requester; 

Wherein said central authority comprises : 

gQ - means for establishing a financiaf transaction (9) with said requester for the payment by the requester of the 

content proposed by said responder and for delivering the proof of buying (10) to sard requester; and 
a responder compensation means for providing said responder with a compensation In exchange of the buying 
of a content by a requester. 

^3 2. Method for distributing a digital content through a sharing network (1 1 0) using the system according to claim 1 , 
characterized in that it comprises the steps consisting for a responder (300) in: 

a) fO response to a request (1) for a digital content received from a requester (200) through safd sharing 
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network, sending content purchase infomnation data (4) to said requester ; 

said content purchase Information data rncfuding a responder identifier generated by a central authority 
(201 - 204) and data identifying said central authority ; 

b) receiving from said requester (200) a proof of buying (11) of said digital content, said proof of buying being 
delivered by said central authority ; 

c) providing said requester (200) with a data file corresponding to said digital content; and 

d) receiving from said central authority a compensation for the distribution of said digital content. 

3- Method according to claim 2, further comprising before step a) a registration step comprising: 
receiving from said central authority a responder identifier. 

4. Method according to daim 3, wherein said registration step further comprises: 

'5 receiving from said central authority a first symmetric encryption key (DKpp) derived from a first central au- 

tif^ohty master key (MKpp^) and from said responder identifier. 

5. Method according to daim 4, wherein said registration step further comprises: 

^ receiving from said central authority a second symmetric encryption tcey (DKec) derived from a second central 

authority master key (MK^q) and from said responder identifier. 

6. Method for distributing a digital content through a sharing networl< (1 1 0) using the system according to claim 1 , 
characterized in that it comprises the steps consrstmg for a requester (200) in: 

25 

\) sending through said sharing network a first message (1 ) to request a digital content ; 

j) receiving content purchase information data (4) from a responder having a data file corresponding to said 

content; 

said content purchase information data including data identifying a central authority; 
30 k) in response to a financial transaction (9) with said central authority, receiving a proof of buying (1 0) of said 

digital content; 

I) sending said proof of buying to said responder (300); and 
m) receiving a data file corresponding to said digital content. 

35 7. Method according to daims 2 or 6, wherein said content purchase information data comprises content price data 
(3) received by said responder from said central authority, said content price data being determined by the central 
authority for each responder 

8. Method according to claim 7, wherein said content purchase informatbn data further comprises a price time validity 
data. 

9. Method according to claim 4, wherein said content purchase infomnation data comprises content price data (3) 
received by said responder from said centraf authority, said content price data being detemiined by the centraf 
authority for each responder, 

and wherein said content price data are sent in a message (3) encrypted using said first symmetric encryption 
key(DKpn). 

10. Method according to claim 5, wherein said proof of buying is sent in a message (11) encrypted using a symmetric 
session key (SSK), 

50 said symmetric session key (SSK) being derived by the central authority from a random value and from said 

second symmetric encryption key (DKec)i 

said random value being sent in clear in the message (11) containing said encrypted proof of buying, 

55 
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